home *** CD-ROM | disk | FTP | other *** search
- Path: news.nyu.edu!schonberg!dewar
- From: dewar@cs.nyu.edu (Robert Dewar)
- Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
- Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
- Date: 10 Apr 1996 23:16:27 -0400
- Organization: Courant Institute of Mathematical Sciences
- Message-ID: <dewar.829192575@schonberg>
- References: <JSA.96Feb16135027@organon.com> <dewar.828879781@schonberg> <4k9qhe$65r@solutions.solon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <dewar.829011320@schonberg> <4khevn$26a@janus.pec.co.nz>
- NNTP-Posting-Host: schonberg.cs.nyu.edu
- X-Newsreader: NN version 6.5.0 (NOV)
-
- John suggested
-
- " /* Try to protect the user a little bit from left over garbage: */
- memset(&buf[avail], nbytes-avail, 0); /* zero out buf[avail..nbytes-1] */
- return avail;"
-
- Interesting, the spec is really not clear on whether this is a valid
- implementation. I can easily imagine a programmer whose unwritten
- rules would rule out this interpretation and who might assume that
- code which
-
- (a) preinitialized the buffer to blanks
- (b) used read to read into part of this buffer
-
- should be able to expect trailing spaces and not zeroes,
-
- but here again, the spec is insufficiently clear I would say, so this is
- another nice example of possible portability problems that come from
- a vague spec.
-
- That trailing spaces code will probably work in most (all) implementations
- of read, and I can imagine some (injudicious? or perhaps informed by
- a different set of "unwritten rules") programmer assuming it would work.
- Then an implementatoin would do as John suggested, which certainly is
- not unreasonable, and lo and behold, another portability problem that
- could have been prevented by a precise spec.
-
-